USA Bestseller/USA BESTSELLER Vol 1-95 (Hepp-Computer)(1995).iso/e214/ideboost.txt

Text File | 1994-10-17 | 22KB | 421 lines

SHAREWARE VERSION IDE BOOSTER

IDE Booster will shut down after 10,000 reads/writes.  This should give
the average user about 8 hours of testing time to evaluate if IDE Booster
is effective.  The counter is reset after rebooting the machine allowing
for another 10,000 reads/writes to the disk.  The registered version of
IDE Booster allows for unlimited reads/writes.


The block device driver for AT/IDE interface hard disk drives that
enables MULTIPLE SECTOR Block Transfer Mode.

IDE Booster is a block device driver that is designed exclusively for
AT/IDE Hard Disk Drives. Many newer IDE drives have the built in
capability to significantly increase their Data Transfer Rates by
activating the MULTIPLE SECTOR Block Transfer Mode. In a typical
scenario, the transfer rate can be increased by up to 45% over the
rate offered by the motherboard bios. Some of the newest motherboards
and high-end Host Adapters are beginning to offer this MULTIPLE Mode,
but this great feature of our new IDE drives has essentially remained
untapped.... until now, thanks to IDE Booster!

┌────────────────────────────────────────────────────────────────────┐
│▒▒▒ Command Line Switches ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒│
└────────────────────────────────────────────────────────────────────┘

No Command Line Switches - Driver will NOT load since it requires the
                           command line switches for instruction.

B(?)xx - Block Size of xx for Unit ?. Where (?) is replaced by either
         0 or 1 and xx is replaced by a value (typically an even
         number) indicating the number of Sectors Per Block (SPB).
         The SPB value cannot exceed the maximum number of sectors per
         interrupt defined in the drive's own microcode.

RM(?) - Activate READ MULTIPLE for unit ?= 0 or 1.

WM(?) - Activate WRITE MULTIPLE for unit ?= 0 or 1.

P - Pause the progress of the config.sys after loading IDE Booster.  Press
    C to continue.  This is handy when confirming the status of the
    driver.

Example:

device=IDEBOOST.EXE B016 RM0 WM0 B132 RM1 P

         means: block size of 16 for unit 0 with READ and WRITE
                MULTIPLE, block size of 32 for unit 1 with READ
                MULTIPLE only, with a "Press C to Continue" pause
                after loading.

┌────────────────────────────────────────────────────────────────────┐
│▒▒▒ Background ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒│
└────────────────────────────────────────────────────────────────────┘

MULTIPLE SECTOR Block Transfer Mode has its origins in the ESDI hard
disk drive interface.  Just prior to the development of the AT/IDE
interface, the ESDI controllers were about ready to institute this
very interesting ability.  Similar to the IDE inquiry command, ESDI
drives will report 512 bytes of information about themselves where
word 47 is a yes/no variable about Multiple Sector capability.  If the
byte is "yes" then the following bytes will tell how many maximum
sectors per interrupt may be used.

The rapid pace of hard drive technology, however, has since made the
ESDI interface obsolete.  This is lamentable from the standpoint that
the interface has a sterling reputation for quality and the drives for
ruggedness.  ESDI drives were typically large capacity units (of the
time) that found homes in file servers and other environments that
demanded critical performance from their drives.  Most network
managers will speak highly of the interface.

Drive manufacturers soon found that the cost per megabyte could be
drastically reduced by building the controllers directly onto the
drive.  This concept holds true for the AT/IDE interface (as well as
SCSI, but that's a whole different ball game).  This integrated
controller also allowed the drive manufacturers to use Zone Bit
Recording methods (variable sectors per track) and drive geometry
translation schemes to exceed the DOS limitation of 1024 cylinders
max.  By building RAM buffers into the drives we finally begin to
reach the point in hard drive technology where MULTIPLE SECTOR Block
Transfer Mode begins to be a reality.

A discussion about the microcode which manages the drive RAM buffer is
worthwhile.  Just like the RAM memory in our systems, the RAM buffers
on an AT/IDE drive should be thought of as a "memory pool". Today's
modern drives have buffers that range from simple to sophisticated. The
simplest buffer schemes employ basic Read Look Ahead techniques that
operate on the assumption that the next data you will request will be
contiguously after the data you just got.

These Look Ahead buffers generally are FIFO types (first in, first
out) that either read a pre defined number of sectors, or read through
to the end of the physical cylinder.  It is easy to imagine that the
transfer rate and speed of the data delivery to the host system is
greatly increased when it is dumped from RAM to RAM (nanoseconds)
instead of physically picking it up off of the drive (milliseconds).

The early AT/IDE drives had buffers of only 2 to 8 KiloBytes.  In
terms of sectors, that is 4 to 16 (2 512 byte sectors equal 1
KiloByte). This is enough to Read Ahead the rest of a track of a 17
sector per track drive (typical of the day).  Reading Ahead to the end
of the cylinder requires a much larger amount of memory.  Also, basic
competition amongst the drive manufacturers to be faster "than the
other guy" has caused the buffer sizes to increase.  Other factors
like spindle speeds, recording densities, and access times combine
together to be part of the overall improvements that have increased
drive performance.

When the RAM buffer reaches a certain point in size, either the Read
Look Ahead must cross a physical cylinder boundary or something else
more desirable; this moves us into Segmented Buffers.  From here we
see Adaptive Segmented Buffers, and so on.  A typical modern drive may
describe its buffer as Read Look Ahead Multi-Segmented Adaptive,
combining all types.

Write caching is the current newcomer to drive buffer techniques.
These are interesting in that the drive reports that a write has
completed as soon as the data arrives in the buffer, thereby freeing
up the interrupt hold on the CPU, allowing it to move on to more
processing. Then the drive, under its own control, attends to laying
down the data on the spinning magnetic media.  This happens very
quickly and does not carry with it the same negative implications that
some report about write caching software.

The balance between RAM allotted to write cache and read cache is
usually preset to around 40/60 and may someday actually dynamically
adjust to true system usage.  You can begin to see that these models
employ sophisticated microcode and algorithms working with a memory
pool which is subdivided into various areas.  The size of this total
buffer memory is climbing continuously, with state-of-the-art models
offering 1 megabyte of RAM. (Why do I get the feeling that this will
be old news in a few months.... <grin>?)

So, what about MULTIPLE SECTOR Block Transfer?  Simple, really...
whatever Block Size is set, is deducted from the memory pool.  For
example, if a 32 sector block is set, then 16 KiloBytes of RAM are
removed from the Read/Write caching on the drive.  While this sounds
like a setback, an actual increase in the Data Transfer Rate results
from the way this can interact with DOS.

┌────────────────────────────────────────────────────────────────────┐
│▒▒▒ Outline ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒│
└────────────────────────────────────────────────────────────────────┘

Fortunately for all of us, the convenience of personal computers is
due, in large part, to the simplification of the User Interface.  We
have the advantage today, over the early pioneers, of being able to
simply sit down and create within our applications.  We "suspect" that
low level hardware operations are taking place as we work, because the
equipment tends to respond to our commands.   We see the hard drive
activity light flicker when we open and close our files.  This is as
it should be for the popular acceptance of personal computers in our
society.  User Interfaces have become friendlier each day, and will
continue to do so.  We can all look forward to the near future when
systems interact with more than just our fingers.

In some respects, interface is synonymous with translator.  As we work
within our high level applications, layers of translations are taking
place to convert our commands into machine language.  We enjoy the
benefit of not needing to know how these clever manipulations are done
and can count ourselves lucky in the process.  A typical read
translation sequence might be as follows:

1.  Application Command Open File

     This level has its own layers of simplification, but roughly
     boils down to the fact that as a programmer's source code is
     prepared for use, a compiler translates the file handling
     components into the standard DOS level software interrupts,
     notably Interrupt 21.

source code:   assign DataFile the name mydata.dat
               open (DataFile)
               read (DataFile, DataWeNeed)  : Int 21, Fn 3Fh
                                              so many sectors...
               close (DataFile)
               use (DataWeNeed)

     These DOS interrupts provide even the programmer with the ability
     of being able to avoid low level interaction with the system and
     allows an application to operate on many types of machines.  Once
     an application issues a DOS file command, the programmer can
     count on a trustworthy sequence of events and can just let it
     happen while waiting for a confirmation of success from the
     operating system. (Some say that a REAL programmer always begins
     with COPY CON PROGRAM.EXE <groan>.)

2.  DOS File Allocation Table (FAT)

     The resident portion of our operating system, that part which
     always stays in memory, is triggered into action by the DOS read
     file interrupt.  The first order of business is to determine if
     the file already exists, and if it does... where?  The DOS file
     directories are used to make this determination and give the
     operating system a starting point.  DOS uses a method of ordering
     our data into clusters, or groups of sectors, that begins with
     zero and numbers on up to the end of a drive's partition. This
     might be thought of as a kind of linear, two dimensional map and
     is sometimes call logical block address.

     Since most files are larger than a single cluster, the location
     of the next cluster after the start is required.  This location
     of the next portion of the file is determined by inspecting the
     File Allocation Table.  This table tells DOS the logical
     whereabouts of the next data; which does not necessarily
     contiguously follow the location of the last data. With DOS
     reading the data into memory as it goes along, these steps are
     repeated until the end of the file is reached.  The link from
     location to location create a virtual chain of connections that
     insure that data is not lost.

3.  DOS Kernel Resident Block Device Driver

     To this point the data is logically ordered in the two
     dimensional manner described above. Yet, we need to translate
     this into a specifically located sector on the drive, itself.
     Disk drives order their data by Cylinders, Heads and Sectors
     which is a kind of spacial three dimensional coordinate.  The
     transition from the logical linear location to the physical
     spacial location is the job of DOS's own Resident Block Device
     Driver (Block a.k.a Disk).  This requires a straight forward
     calculation whose result depends on the individual geometry of
     the drive being accessed; this geometry is stored in the Boot
     Records and things called Bios Parameter Blocks and is read into
     memory when the operating system loads.

     If an imaginary drive had 10 sectors per track, 10 heads, and 10
     cylinders, the drive would have a total of 1000 sectors. If we
     were to count up through the sectors, the Heads digit (10's)
     would increment after the ninth sector and the Cylinders digit
     (100's) would increment after the ninth head.  With this model,
     it is easy to see the relationship between the logical and
     physical locations.  For example, the 123rd logical sector might
     physically be located at Cyl=1, Hd=2 and Sect=3.  Aside from the
     fact that DOS doesn't recognize a zero in the sectors digit, this
     is the oversimplified way things are.  Disk drives, however, come
     in many different capacities and make calculating a physical
     location more interesting.  A drive with 17 Sectors per track, 6
     Heads and 820 Cylinders would find the 123rd sector at Cyl=1,
     Hd=1 and Sect=3 (right?).

4.  Interrupt 13 Call

     Fun and games aside, the DOS Block Device Driver then builds a
     hardware interrupt command that says something like "unit 0, at
     cylinder 1, head 1, sector 4... read it."  Things start to look
     just like assembly language programming at this point:

     mov ah, 02h   ; read function
     mov al, 1     ; number of sectors
     mov ch, 1     ; cylinder number
     mov cl, 4     ; sector number
     mov dh, 1     ; head number
     mov dl, 0     ; unit number
     int 13        ; disk interrupt

     Believe it or not, the fact is we still are looking at a language
     designed to provide a user friendly interface, really.  Many
     programmers actually write their programs at this level because
     the finished and compiled  code ends up being smaller and faster
     than the code produced by higher level programming languages like
     Basic, Pascal and C.

5.  AT BIOS Port Address Command

     Interrupt 13 Function 02h is a program, too, in a way. Its
     routines are provided on a chip we all have someplace in our
     system, called a BIOS (Basic Input Output Services).  When we
     power on the computer the contents of the BIOS are stored in
     memory and everything we do flows through these routines.  All
     the hardware components of the computer - video, disk, keyboard,
     etc. - have complicated little routines which handle
     communicating with the hardware device.

     Repetition is the name of the game at this level.  In the case of
     our read a file example, every involved sector is seeked to
     (sought?), read from and checked out for success, individually.
     What is simplified for convenience as Int 13 Fn 02h ends up being
     a near endless stream of machine language Port Address commands.
     Hard disk drives have a specific port address at 1F0h for the
     Primary port address and 170h for the Secondary port address.
     While Int 13 serves both hard and floppy disk drives, the port
     addresses for these two different types of drives are split apart
     and managed by separate BIOS routines.

6.  Enter IDE Booster

     We've finally reached the level where it is time to consider how
     IDE Booster figures into the scheme of things.  First, it is
     important to look at the challenge faced by the BIOS programmer.
     The hard disk drive to be used in the computer system will be one
     of many hundreds of types across several interfaces that range
     from old to new, all needing to be supported by the one BIOS
     routine.  Given this obligation, the routines that are written
     are understandably generic with the same code that runs our older
     MFM drive also running our new AT/IDE drive.  The need for
     general compatibility creates a situation where the special
     enhancements of the modern AT/IDE disk drive are left
     unsupported.

     The phrase "Multiple Sectors Per Interrupt" correctly implies the
     notion that normally we have only one sector per interrupt. This
     is the case with the standard BIOS service and is the default
     start up configuration of the drive.  The following diagram shows
     that a large amount of time is spent in overhead checking the
     interrupt after every sector read from the port:

     Interrupt Confirmation (overhead)
     │
    ┌i┐   ┌i┐   ┌i┐   ┌i┐   ┌i┐   ┌i┐   ┌i┐   ┌i┐   ┌i┐   ┌i┐   ┌i┐
 s──┘ └s──┘ └s──┘ └s──┘ └s──┘ └s──┘ └s──┘ └s──┘ └s──┘ └s──┘ └s──┘ └s─
 │
 Sector Read


     With Multiple Sector Block Transfer Mode enabled on the drive,
     block size equals to 8, a flow of data like this results:

                                 Interrupt Confirmation (overhead)
                                 │
                                ┌i┐                               ┌i┐
 s───s───s───s───s───s───s───s──┘ └s───s───s───s───s───s───s───s──┘ └
 │
 Sector Read

     A new routine is required to pass this type of data flow back to
     DOS; software of this type is called an Interrupt Service Routine
     (ISR). IDE Booster is an ISR replacement for the native BIOS Int 13
     read and/or write hard disk drive service routines.  IDE Booster
     resides in memory, monitoring all Int 13 requests.  When a Read
     and/or Write request comes along, it intercepts the command and
     manages it directly, "hand carrying" it through to the
     port addresses, and the drive.

     The turn around time on the delivery of the data is significantly
     improved because much of the overhead from the interrupt
     confirmations has been eliminated. This causes the Data Transfer
     Rate to increase significantly.  IDE Booster is loaded as a device
     driver through the Configure System CONFIG.SYS file.  Since
     IDE Booster operates at such a low level, it remains compatible with
     virtually all applications.  A few noteworthy exceptions do exist
     and are noted in the App Notes section, below.

┌────────────────────────────────────────────────────────────────────┐
│▒▒▒ App Notes ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒│
└────────────────────────────────────────────────────────────────────┘

Some Application Notes:

 1.  We've seen a few programs which provide an interesting "public
     safety" feature, namely that they block attempts to  write to
     track 0 (i.e. cylinder 0, head 0).  The purpose is to provide a
     layer of defense against boot sector viruses. Since this is such
     a good idea, we decided to join in and provide the same
     protection.  After all, our device driver is custom tailored to
     reading and writing to the hard disk drive and this capability
     only added a byte or two of additional code. IDE Booster provides
     this general safety precaution because no legitimate applications
     have any business, whatsoever, writing changes to sectors on this
     track without your knowledge.

     Reading data on track 0 is allowed, however writing to track 0
     will produce a write protect error.  If you need to modify data
     on these "hidden" sectors, then you will need to REM out the
     device=dqwik110.hdd statement in the config.sys, and reboot.

 2.  Drive compression software programs like DoubleSpace work
     perfectly well with IDE Booster.


 4.  Concerning Windows Swap Files: A Temporary swap file works
     because the file is like any other typical file with FAT updates.
     A Permanent swap file doesn't work because it is unlike any other
     typical file.  Basically, a permanent swap file locks itself into
     an area on the drive and never moves, and since it never moves,
     DOS and FAT updates are no longer required. A permanent swap file
     is read and written directly with Int13 and cannot handle
     multiple sector block transfer mode.  Windows should refuse to
     load if it sees an Int13 interrupt service routine like IDE Booster.

     We'd like to point out that the net gain in data transfer rate,
     while in Windows, from using multiple sector block transfer mode
     access to a temporary swap file far exceeds the gain of using
     native Int13 access to a permanent swap file.

 5.  DOS version levels and OEM versions of DOS work because they all
     follow the same standards accessing Int13.

 6.  When determining the value for Sectors Per Block (SPB) in the
     registered version, it is worth noting that the rate of change in
     the Data Transfer Rate tends to level out around 32 sector per
     block. Even if your drive says it can handle a higher amount,
     you'll probably find the increase is fairly small and not really
     worth it considering the RAM requirement is removed from the
     drive's buffer memory pool (i.e. read/write caching on the
     drive).

 7.  The Sector Per Block value can be odd or even values, however
     setting values to  2, 4, 8, 16, or 32 seem to make better sense
     as they are more adapted to the math routines involved.

 8.  File defragmentation and optimization utilities will generally
     work well with IDE Booster, however it is a good practice to
     simplify one's system before running this type of utility by
     disabling programs like drive caching software and IDE Booster.
     Always make sure you have a current backup before optimizing a
     hard disk drive.

┌────────────────────────────────────────────────────────────────────┐
│▒▒▒ Error Messages ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒│
└────────────────────────────────────────────────────────────────────┘

The device driver may display a single of error message during the
loading process of the CONFIG.SYS file.  It is "Error Loading
IDE Booster" and results from the drive returning an aborted command when
the set multiple command is issued.